feat(ooxml.js): record a pptx slide's reading order as a rank per shape - #1199

`readPptxContent` returns `ContentSlide.shapes` in `p:spTree` order,
which is z-order -- roughly creation order -- and bears no relation to
layout. That is fine for a consumer rendering the shapes, since each
carries its own frame. It stops being fine for one reading a slide as
prose: in spTree order a column of bullets can precede the heading that
owns them, which the same deck exported to PDF does not do, because a
PDF renderer has already resolved layout to reading order.

`ContentShape` gains an optional `readingOrder`, recovered from the
shapes' own geometry by recursive XY-cut: find a band of empty space no
shape straddles, take the groups either side in order, recurse, and fall
back to topmost-then-leftmost where a set overlaps on both axes.

**A rank on the shape, not a reordered array**, expressed exactly as
`paintOrder` already is -- including the same plain `z.number()`, for
the same reason its comment gives: a fractional value can be inserted
between two existing ones later. `sourcePath` is assigned as
`slides[N].shapes[N]` and has to keep naming the position it names, so
sorting the array would either desynchronise every path or redefine
sourcePath away from the document order its own comment promises. The
array is returned untouched; a consumer wanting reading order sorts by
the rank, and one that does not is unaffected.

Two details that took measuring, both covered by tests:

The axis is chosen per cut rather than always cutting rows first, which
is what keeps a two-column slide readable -- where each column is a
heading above its own list, cutting rows yields both headings then both
lists. On a title-above-body slide the same comparison comes out the
other way round.

The gap is compared *relative* to the extent the shapes occupy on each
axis, because a 16:9 slide is nearly twice as wide as it is tall: an
absolute comparison reads a four-box grid down its columns instead of
across its rows.

Additive and optional throughout, so no existing consumer changes
behaviour. `ShapeDescriptor`'s hand-authored JSON Schema fragment is
updated to match; the `ContentVector` variants deliberately are not,
since they carry `paintOrder` but have no reading order of their own.